1. Field of the Invention
The present invention relates to the field of telecommunications. More particularly, the present invention relates to a system and method for establishing a virtual private network (VPN) over a telecommunications network.
2. Description of the Related Art
Currently, there are two basic approaches that are used for setting up a virtual private network (VPN) between two sites. The first approach is a distributed management approach that involves each site independently configuring a local VPN device, such as a network access server (NAS). Critical network parameters are then communicated between each site for configuring the VPN. The second approach is a centralized management approach that uses software at a centralized location to enter the configuration parameters for each VPN device when a VPN is to be established. The centralized software then uploads the configuration files into each respective VPN device so that the VPN can be established.
For the distributed management approach, each site independently requests a certificate from a certification authority for each VPN device that is controlled by the requesting site. The certification authority verifies the information contained in the certificate request by verifying the identity and ownership of the public key for the VPN device. The certification authority then generates a certificate and delivers the certificate to the requesting site. A system administrator at the requesting site then installs a VPN device using the new certificate. Subsequently when a VPN is established between the two sites, detailed network parameters are communicated between system administrators for each site, such as a telephone, for each VPN that is established. The communicated network parameters are then manually entered into each respective VPN device by the respective system administrators for each VPN that is to be established.
FIG. 1 shows a system block diagram illustrating a specific example of a conventional distributed approach for establishing an Internet Protocol Security (IPSEC) LAN-to-LAN VPN connection between, for example, a Company A and a Company B. Company A and Company B each has a separate respective local area network (LAN) LAN 101 and LAN 102. Terminal devices, such as personal computers (PCs), are connected in a well-known manner to each respective LAN. While only one terminal device 103 and one terminal device 104 are shown respectively connected to LAN 101 and LAN 102 in FIG. 1, it should be understood that a plurality of terminal devices can be connected to each LAN, but are not shown. Moreover, it should be understood that other well-known terminal devices other than PCs could be connected in a well-known manner to LAN 101 and LAN 102, such as printers, databases, etc.
Company A and Company B are each respectively connected to a telecommunications network 100, such as the Internet, through VPN devices 105 and 106, such as a network access servers (NASs), a firewall or a VPN gateway. While only VPN devices 105 and 106 are shown in FIG. 1, it should be understood that each of Company A and Company B can be connected in a well-known manner to telecommunications network 100 through a plurality of VPN devices. Telecommunications network 100 includes routers 107-109. While only routers 107-109 are shown in FIG. 1 for simplicity, it should be understood that telecommunications network 100 includes a variety of well-known telecommunications devices that are not shown.
When, for example, a user at terminal device 103 desires to establish a VPN to a user at terminal 104, each respective user contacts the local system administrator and requests that such a VPN be established. Detailed network parameters must be provided at both sides of the VPN tunnel for securely establishing the range of IP addresses that are to be routed into the VPN link or accepted from the VPN link. The respective system administrators for each site then communicate the detailed parameters, for example, over a voice or facsimile link 110. Each system administrator manually enters the communicated network parameters into a VPN configuration file for the desired VPN at the local VPN device. The configuration file is then used by conventional LAN-to-LAN VPN software for establishing the desired VPN. Exemplary parameter information contained in a VPN configuration file at Company A includes:                Left_ID=companyA.com        Left Key=companyA.com.x509        Left_IP=10.0.0.1.        LeftSubNet=192.168.0.0/255.255.255.0        LeftNextHop=10.0.0.2;        RightID=companyB.com        Right_Key=companyB.com.x509        RightIP=11.0.1.1        RightSubNet=192.168.1.0/255.255.255.0        RightNextHop=10.0.1.2        IPsec_Type=tunnel-esp-3des-md5-96        ReKeyRate=8h        AuthenticationType=ike-rsasig        
Exemplary parameter information contained in a VPN configuration file at Company B includes:                Left_ID=companyB.com        Left_Key=companyB.com.x509        Left IP=10.0.1.1        LeftSubNet=192.168.1.0/255.255.255.0        LeftNextHop=10.0.1.2        Right ID=companyA.com        Right_Key=companyA.com.x509        RightIP=10.0.0.1        RightSubNet=192.168.0.0/255.255.255.0        RightNextHop=10.0.0.2        IPsec_Type=unnel-esp-3des-md5-96        ReKeyRate=8h        AuthenticationType=ike-rsasig        
Each new VPN defined between the LANs of Company A and Company B requires that network parameters that are similar to those that are listed above be entered into each respective VPN device. Because specific parameters about a destination LAN that will be connected to through the VPN are required, merely trusting the “other side” to provide the required parameters could result in an invalid range of IP addresses being provided to a site. Moreover, a middleman could, from the point of view of each end of the VPN, pretend to be the “other” system administrator and cause the VPN to be routed through a particular node, thereby making the information being conveyed over the VPN vulnerable to a “man-in-the-middle” attack.
Another problem associated with a conventional distributed approach for establishing a VPN is that often times there is a lengthy wait before a LAN-to-LAN VPN is established because key network administration personnel at the two respective LAN sites must communicate and manually enter the correct network parameters into each local VPN gateway so that the VPN can be established. In many cases, the effort required for establishing a LAN-to-LAN VPN is so burdensome, that a VPN is avoided entirely, and network encryption/authentication is addressed at the application layer using the secure sockets layer (SSL) protocol.
The second approach for conventionally establishing a VPN is the centralized management approach. FIG. 2 shows a system block diagram illustrating a conventional centralized management approach for establishing a VPN. In FIG. 2, a centralized authority 201 completely controls and configures all VPN devices, such as VPN devices 202-204, at remote sites that are connected to a telecommunications network 205, such as the Internet. When certificates are used, centralized authority 201 processes all certificate request information and acts as the certificate authority. Alternatively, outside certificate authority can be used for verifying the information and for generating a certificate. A system administrator from centralized authority 201 then installs the certificate in the VPN device of an entity requesting a certificate. Additionally, an administrator at the centralized authority site also enters network parameters for each VPN device into a single piece of software that is stored centrally at centralized authority 201. When a user at a remote site, such as the remote site associated with VPN device 202, desires that a VPN be established with, for example, VPN device 204, the user contacts centralized authority 201 at 206 using, for example, a telephone call, e-mail or by facsimile, requesting the VPN. A system administrator at centralized authority 201 configures each VPN device based on the respective parameters associated with each VPN device. The configuration is then remotely uploaded into each respective VPN device at 207 and 208 so that a VPN can be established between VPN device 202 and VPN device 204.
One problem associated with the centralized management approach is the inherent time delay that a user experiences between the time that a VPN is requested and the time that the VPN is finally established. Another problem is that each remote site does not have control over the VPN device located at the site.
There are many currently-available VPN software solutions that simplify the administration and connection of a large number of clients (i.e., single IP address remote computers) for a corporate LAN, that is, when the IP address of the VPN tunnel device and the client address of the VPN are the same: In such situations, authentication of VPN parameters by a third party is not important.
Nevertheless, in view of the foregoing, what is needed is a way to simplify administration for establishing a large number of LAN-to-LAN VPNs. Moreover, what is needed is an approach to configuring LAN-to-LAN VPNs that does not require a LAN organization to manually configure parameters for each new tunnel, or to give up control of their VPN device to a central authority.